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SPECIFICATION 
TITLE 

METHOD OF MONITORING FOR AVAILABILITY OF A SYSTEM FUNCTION IN A 

COMPUTER SYSTEM 

BACKGROUND OF THE INVENTION 



Field of the Invention 

[0001] The invention relates to a method and respective component and 

system for monitoring the availability of a system function when a change in the 
state of a component of the system has taken place or is intended. 

Description of the Related Art 

[0002] Previously, digital switching systems (e.g., the systems EWSD and 

EWSX from Siemens AG) contained no function which monitored particular 
functionalities distributed over a large number of hardware (HW) units (platforms). 
This created the following technical problems: 

[0003] - If HW units were no longer active on account of errors 

(hardware HW or software SW), the operator himself had to deduce which 
functionalities of the system had been lost. 

[0004] - Routine tests on HW units meant that there was the possibility 

that particular functionalities were no longer available, since HW units were 
automatically disconnected during routine tests. 

[0005] - An operator was able to deactivate HW units without receiving 

any indication of which functionalities of the system would be lost as a result of the 
deactivation. 

[0006] Of the problems indicated above, only the first has been partially 

solved: 

[0007] - Detection of whether a particular functionality is not available in 

the system was provided exclusively during the startup phase (in EWSD: 
adjudgement of #7 total failure). 
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[0008] - Upon adjudgement of #7 total failure, initiation of a recovery 

escalation. 

Drawbacks of this solution: 

[0009] During normal operation, there is, to date, no direct adjudgement of or 

5 monitoring for loss of an important system function. 

[0010] There is also no predictive assessment of whether a fundamental 

system function will be lost on account of an HW configuration. 

SUMMARY OF THE INVENTION 

[001 1] The invention is based on the object of overcoming the 

aforementioned drawbacks. 

[0012] This object is achieved by a method of monitoring for availability of a 

system function in a computer system, comprising the steps of storing, in a 
database of said computer system, for a system function monitored for availability, 
respective information which describes conditions under which said availability of a 
system function are to be assessed as existing or no longer existing; and utilizing 
said information, when a change in a state of a component of said computer system 
has taken place or is intended to take place, to assess whether said change that has 
taken place results, or said change that is intended to take place would result, in a 
change in terms of the availability of said system function. 

[0013] According to the invention, an arbitrary system functionality indicated 

by the network operator is mapped in the database using the data types and the 
loading types of the HW units. The mapped data are provided with a functional 
state, are maintained and are assessed on the basis of the system state (including 
predictively). 

25 BRIEF DESCRIPTION OF THE DRAWINGS 

[0014] The invention is explained in more detail below with reference to the 

drawings. 

[0015] Figure 1 is a block diagram showing a general association between 

data types and HW units; and 
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[0016] 



Figure 2 



* 

is a data structure diagram illustrating data types that may 
be available on various HW units MP-Dep. 



DETAILED DESCRIPTION OF THE INVENTION 

[0017] Figure 1 illustrates the entire system having a functionalities in 

5 subsystem 1 (with data types A and B) and subsystem 2 (with data types C and D). 
Platform x is shown having both data types A and B, and platforms y and z having 
only data type A and B respectively. 

[0018] The following (operator-related) data types exist on the systems 

EWSD and EWSX: 



m 10 


[0019] 


- CALLP 


(Data for call processing operations) 


a 


[0020] 


-CM 


(Data for call processing operations) 


y] 


[0021] 


- SLT 


(Data for #7 signaling and other signaling types) 


w 


[0022] 


-SM 


(Data for #7 signaling) 




[0023] 


- PNNI 


(Data for private networks) 


m 15 

h! 


[0024] 


- MN 


(Data for mobile radio) 




[0025] 


- PD 


(Data for mobile radio) 


t £_ 


[0026] 


-LIC 


(Data for a line termination) 




[0027] 


Examples are illustrated in Figure 2. 




[0028] 


In addition to the data types mentioned, the loading type of an HW unit 



2 0 determines whether or not this HW unit is relevant in the context of total failure. 

Thus, by way of example, the data type SLT is used on the basis of its loading type, 
i.e., all MP-Deps having the data type SLT hold the same data. The loading type is 
used to decide which processes ultimately access these data and process them. 

[0029] The combination of data type and loading type stipulates what 

2 5 functionality is provided by a particular HW unit. Thus, an MP-Dep having the data 
type SLT may or may not be relevant to #7 signaling, depending on the loading type. 
To illustrate more simplistically, the designation #7-SLT is used below when the 
loading type of the MP-Dep means that it is relevant to #7 signaling. Otherwise, just 
the designation SLT is used. 
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[0030] If, by way of example, the system functions "call processing" and "#7 

signaling" have now been assessed as being relevant in the context of total failure, 
the check on the availability of the call processing functionality needs to be assured 
of the availability of at least one MP-Dep from the set [MP-Dep 1x and MP-Dep 2x] 
5 in the example in Figure 2. For the #7 functionality, the MP-Deps 1x f 2x and the MP- 
Dep 40 need to be checked. 

[0031] Since the network operator would usually wish to define the instant at 

which system functions are to be assessed as relevant to failure, the 
aforementioned check must be of flexible design. This is achieved as follows: 

10 [0032] - The components (HW units) of the system are mapped in the 

database, 

*P [0033] - for a mapped component, a respective record is made of 

CO 

ijj whether, on the basis of its data and loading type, this component is necessary for 

« one or more system functions which are relevant in the context of failure (the details 

33 15 required for making the aforementioned record can be prescribed by a network 

g " operator, for example), 

£K5=j 

m [0034] - for a component mapped in this way, an additional record is 

made of the instant (e.g., during startup, after startup, or at any time) at which this 
component is necessary (the details required for making the aforementioned record 
20 can likewise be prescribed by a network operator), 

[0035] - for each system function, the minimum number of the mapped 

components which are needed to maintain this very system function is also 
stipulated, 

[0036] - for a mapped component, its respective (functional) state is also 

2 5 recorded, i.e., whether or not it is active, 

[0037] - this state (active/not active) is maintained by the maintenance 

SW already existing for this purpose, 

[0038] - any change in a state is reported to a total failure detection unit, 

[0039] - in this context, this report may be sent before or after a change 

3 0 in a state, 
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[0040] - if this report is sent before the change in a state (e.g., if an 

operator wants to deactivate components, e.g., HW units, or if a routine test is to be 
carried out), the total failure detection unit assesses whether deactivating a 
particular component would result in a particular system function being lost, and 
notifies the report originator (e.g., maintenance SW, etc.) of this fact, 

[0041] - if this message is sent after the change in a state (e.g., when a 

component fails), the total failure detection unit assesses whether deactivation of a 
unit has caused a particular system function to be lost. The result of this assessment 
is forwarded to the report originator (e.g., protective SW), 

[0042] - the report originator can now react in the manner which it 

deems appropriate (alarm, rejection of the operator order, rejection of the routine 
test (which would result in the unit being disconnected), repetition of startup, etc.). 

[0043] The above-described method and component are illustrative of the 

principles of the present invention. Numerous modifications and adaptations will be 
readily apparent to those skilled in this art without departing from the spirit and 
scope of the present invention. 
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